In packet telephony or Voice over Internet Protocol (VoIP) networks, there are several protocol stacks that have been defined to facilitate the provision of voice, video and other messaging services. These protocol stacks include H.323, Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP) and others.
H.323 is a standardized communication protocol that enables dissimilar devices to communicate with each other using a common set of codecs, call setup and negotiating procedures, and basic data transport methods.
The MGCP protocol, defined under Informational RFC 3435 (F. Andreasen, B. Foster, “Media Gateway Control Protocol (MGCP) Version 1.0”, RFC 3435, January 2003), incorporated herein in its entirety, is suited for centralized systems controlling IP telephony gateways that operate with endpoints having little or no intelligence, such as analog telephones. MGCP is a plain-text, master/slave protocol that allows call control devices, also referred to as call agents or more generally as servers, to take control of a specific port on a gateway or on an MGCP-controlled IP phone, also referred to more generally as a client or MGCP endpoint. MGCP messages between call agents and MGCP endpoints are sent with Internet Protocol over User Datagram Protocol (IP/UDP). No voice data is transmitted through the MGCP protocol itself. Rather, all the voice data transfer occurs directly between the gateways.
PacketCable is an industry-wide initiative for developing interoperability standards for multimedia services over cable facilities using packet technology. PacketCable developed protocols called Network-based Call Signaling (NCS) and Trunking Gateway Control Protocol (TGCP), which both contain extensions and modifications to MGCP while preserving basic MGCP architecture and constructs. NCS is designed for use with analog, single or multi-line user equipment on residential gateways, while TGCP is intended for use in VoIP-to-PSTN trunking gateways in a cable environment. Hereinafter, references to MGCP are defined to include NCS/TGCP unless otherwise noted.
A mechanism is known by which an MGCP media gateway sends periodic notifications to a call agent using empty Notify (NTFY) MGCP commands. If these periodic notifications are not acknowledged by the call agent with successful or unsuccessful response during a configured amount of time, the gateway determines that the call agent is not available. If the call agent is not available, the gateway switches to a fallback state wherein a default call control application (e.g., H.323) is used to establish future calls. Existing MGCP calls remain active during the fallback state until such MGCP calls are released. The gateway continues to send the periodic notifications to the call agent until a response is obtained. Once a response is received, the MGCP session is reestablished. Existing calls that are being handled by the default call control application will remain active until the calls are released.
The known fallback mechanism is based a non-standard use of the NTFY command which does not meet the requirements for proper message handling defined in RFC 3435. Normally under RFC 3435, a NTFY command may be sent only by a media gateway when a preceding NotificationRequest (RQNT) command has been requested by a call agent. However, sending a NTFY command without an associated RQNT command, as is the case with the known fallback mechanism, does not conform to RFC 3435. A second problem relates to the MGCP “disconnected” procedure. When commands such as NTFY are sent to the call agent and no responses are received, the protocol enters a “disconnected” recovery state for the affected endpoints. A keep-alive mechanism by itself, however, should not lead endpoints to enter this “disconnected” state. Hence, the existing NTFY based mechanism requires special non-standard processing on the gateway to avoid this. Finally, the existing mechanism uses an “all-of” wildcard (*) when sending the NTFY, which is explicitly forbidden in MGCP. In summary, the existing mechanism suffers from several protocol violations which, when observed by the call agent, may lead the call agent to disable the endpoints or otherwise fail normal and intended processing. In addition, the known implementation on the gateway requires violating several MGCP requirements which may have further unintended consequences.